The term “cookie” generally refers to a text-based file generated by a web server and stored on a client's computer for later retrieval when, for example, the client enters a website. A cookie file generally facilitates client navigation within a web site and enable web sites to gather information about users entering the site.
In particular, the cookie file is typically a named piece of data that a web server sends to the client computer, which instructs the client computer to store and send the cookie back to the server each time the client computer transmits a request to that server. The information contained in a cookie file often comprises at least a client ID, which includes a unique number in the form of a name-value pair which assigned to a client upon accessing the web site. The client ID generally includes a name-value pair. For example, a client visiting the website www.goto.com, might receive a cookie file on the client's computer containing a single client ID in the form of a name-value pair as follows:
clientID A9A3BECE0563982D www.goto.com/
Other web sites might store additional information in a cookie file, such as, for example, the cookie generated by www.amazon.com, namely:
session-id-time 954242000 amazon.com/
session-id 002-4135256-7625846 amazon.com/
x-main eKQIfwnxuF7qtmX52x6VWAXh@lh6Uo5H amazon.com/
ubid-main 077-9263437-9645324 amazon.com/
In this example, the information in the cookie file includes a main client ID, an ID for each session, and the time the session began on the client's computer. Cookie data may also contain additional information such as path data, client preference data, geographic information, and/or the like.
Most cookies are also time-sensitive, meaning the cookie is often associated with an expiration date, after which the client computer no longer sends the cookie to the associated server and the client computer removes the cookie from its internal database. Generally, these cookies are classified into two groups, namely a “session-only” cookie which expires automatically when the browser shuts down, and a “persistent” cookie which generally expires at a date and time set by the server.
Web servers may also use cookies to initiate secure sessions. In a secure session transaction, a client visiting a secure web site for the first time is typically queried for client ID and password information. After the client provides the requested information, the information is then compared against a database associated with the server for authentication. Upon valid authentication, a security token is then typically issued to the client. Issuing a security token usually occurs by sending to the client's browser a cookie file with the security token information contained therein. A copy of this cookie information is then sent back to the web server that issued the cookie upon each new web page acquisition, or “clickthrough,” request made by the client within that particular web site. During the secure session, the cookie file is generally configured to expire when the client terminates the browser session, either by logging out of the web site or by closing out the browser.
The server can also utilize the cookie information for session tracking purposes. Sessions often include grouping individual and seemingly unrelated HTTP requests together to identify a particular client's session, as if the requests came across a single persistent connection between the server and the client. Of course, such connections are not persistent, as HTTP is really a connect-and-release protocol wherein a client makes a cormection to the server, sends a request, waits far a response, and then disconnects. This allows the server to service many more clients than would otherwise be possible if all the clients kept their connections open. However, it also means that a session may not be defined by a single persistent connection. Accordingly, many web sites track a user's session by accessing special information within a cookie file, such as a session ID, or even a security token, to maintain a database which logs the various cookie file submissions from a particular client within a given period of time to define a particular session.
Recently, there has been tremendous growth in the utilization of wireless devices, such as cell phones and personal data assistants (PDAs), with web-browsing capabilities. However, these devices usually pose significant challenges to web site operations, particularly in systems seeking to conduct secure sessions, session tracking, and other functionality typically associated with cookie files. Most wireless devices do not support the use of cookie files for various reasons, most notably is memory limitations on the wireless device. Cookie files tend to be very large, sometimes up to approximately 32 kb, and websites typically serve numerous cookie files within a single session. However, wireless devices typically do not have sufficient memory to handle these types of files, making such memory intensive interfaces problematic.
Various methods have been attempted to circumvent this problem. One method requests device-specific information associated with a wireless or handheld device and maps this device information onto a proxy database associated with a server for that device. For example, this information may be mapped onto a gateway between a client and the device. However, protocols for obtaining such information is often device specific such that a server is not always able to determine how to obtain this type of information from a particular device. Moreover, such methods often leave artifacts of device-specific information on third-party servers that are susceptible to cloning. Finally, some gateways do not store all types of cookies files. For example, some gateways permit the storage of only persistent cookie files, while excluding session cookies.
Another method, commonly referred to as “URL rewriting,” essentially eneodes the necessary information onto a URL generated by the server. For example, where a server would normally return a standard URL as follows:                www48.amerieanexpress.com/en/intl?request_type=wl_CardsListHandler&Face=Ja_JP_IMODEa URL rewriting enabled Server might retain the following URL instead:        www48.americanexpress.com/en/intl?requst_type=wl_CardsListHandler &Face=ja—JP_IMODE&sessionid=f0bd52f63fbbf8b3dfdd3abb65e04cle        
In accordance with this method, information that would normally be stored in a cookie is added to the URL string instead. When a request is received from the client, the server looks for this special session information in lieu of a cookie. Here, however, the length of such URL strings tend to become very long, and often surpasses the management capability of many wireless devices. For example, many wireless devices enable a URL capacity of approximately 100 characters or less, whereas many enhanced URL strings may comprise 100 characters or more.
In a related method, secure links are established using URLs where server communication with a client is conducted using secure socket layers (SSL). In this example, the SSL would be placed between the gateway and the server. In another example, unique identification data or session data may be added in a header of an HTTP request. However, this approach is also problematic in that client ID and password data are typically inputted through a Popup logon box, and many wireless devices are not compatible with this type interface.
Accordingly, systems and methods are therefore needed in order to overcome these and other limitations of the prior art.